Graphics rendering is an important part of many representational and interactive applications for computers. In three-dimensional (or ‘3D’) graphics rendering, an image of a 3D rendering space is presented on a display frame as if the space is being viewed through a two-dimensional display plane. As shown in FIG. 1, the display frame 10 is an array of individual picture elements (or ‘pixels’) 30. Each pixel represents a sample of the display plane at a specified location and has a color value that corresponds to the color of the rendering space as viewed through the display plane at that location. For consumer applications, typical sizes for a display frame include 640×480, 800×600, 1024×768, 1152×864, 1280×1024, and 1600×1200 pixels. Computer displays and other high-resolution display devices, such as high-definition televisions (HDTVs), projectors, printers, and the like, present the pixel array to a viewer. The pixels are closely spaced, and the viewer's visual system performs a filtering of the individual pixels to form a composite image. If an image is properly partitioned into pixels that are sufficiently close together, the viewer perceives the displayed array as a virtually continuous image.
In a surface rendering scheme, three-dimensional ‘wire frame’ models of objects in the rendering space are constructed using graphics primitives (e.g. triangles or other elemental polygons). Each primitive is defined by a set of vertices that have values relating to location (e.g. in an XYZ coordinate space), quality (e.g. color and/or texture), and/or lighting (e.g. direction of surface normal). As the positions of the vertices with respect to the display plane include the spatial dimension of depth, or distance from the viewer (also referred to as the Z-dimension), objects may be drawn in front of or behind one another in overlapping fashion.
Some or all of the rendering of the object models into pixels for display may be performed in software. Alternatively, the sets of vertices may be presented to rendering hardware, either directly by the software application or via an application programming interface (API) such as the Direct3D component of the DirectX API suite (Microsoft Corp., Redmond, Wash.) or the OpenGL API (Silicon Graphics, Inc., Mountain View, Calif.).
FIG. 2 shows a block diagram for a 3D video graphics architecture. Such an architecture may be implemented in a video graphics card for use in a personal computer. Alternatively, at least a portion of the architecture may be implemented on a chip package that is integrated into a computer mainboard.
Rasterizer 120 receives a set of graphics primitives for each of the objects to be rendered in a scene. In this example, rasterizer 120 receives each primitive as a triangle having vertices as described above. Rasterizer 120 may receive the primitives from a software application such as a game, simulator, or other imaging application. Alternatively, as shown in FIG. 3, rasterizer 120 may receive the primitives from a transform and lighting engine 110, which may perform coordinate transform and/or lighting operations on the primitives. Rasterizer 120 converts the primitives into fragments, each fragment being a bundle of values to update a particular pixel of display frame 10 as represented in a frame buffer 170. For example, a fragment may include a value for each of the components in the colorspace (e.g. RGB, HSV, YCbCr) and an opacity or ‘alpha’ value. The fragment values may also indicate a corresponding location in the rendering space as well as corresponding locations in one or more texture, lighting, or environment maps.
Rasterizer 120 forwards the fragments to a pixel pipeline 130, where their values may be modified by processing-intensive operations such as smoothing, blending, and dithering and/or access-intensive operations such as texture and bump mapping. The particular operations that pixel pipeline 130 performs on a fragment may depend upon the current configuration of the pipeline (e.g. as defined by the current values of a set of pipeline state variables).
Render backend 160, which receives the fragments from pixel pipeline 130, includes a fragment culler 150 and a pixel combiner 140. Fragment culler 150 discards fragments according to the results of one or more culling tests. For example, fragment culler 150 may perform an occlusion test (or ‘Z-test’) by comparing a Z value of the fragment to a value of Z buffer 180 that corresponds to the same pixel. If a fragment is not discarded by the fragment culler, the corresponding pixel in frame buffer 170 may be updated (e.g. blended or replaced) by pixel combiner 140 according to the fragment's color value. Other values of a surviving fragment may be used to update corresponding locations in other display buffers as well: for example, the fragment's z-value may be used to update a corresponding location of Z buffer 180. When all of the objects to be rendered have been rasterized and incorporated into the display buffers, the contents of frame buffer 170 are modulated onto a display signal (not shown).
In order to enhance the appearance of a generated image, the pipeline may be configured to perform several operations on a fragment. For example, the color and/or alpha values of a fragment may be altered with reference to one or more effect maps (e.g. texture, bump, and light maps). Such operations may be costly in terms of processor cycles and/or memory bandwidth. If the fragment culler subsequently determines that the fragment is occluded and discards it, the resources expended on that fragment in the pixel pipeline (e.g. in terms of processor cycles and/or memory bus usage) have been wasted. It is desirable to reduce such waste.